There are a number of barriers to successful execution of an application on a computer. The computer is operated by an operating system having an executor. The executor executes code or instructions of the application. There are some situations when the executor cannot execute the code contained in the application. Examples of such situations include dividing by zeros and writing to memory that either does not exist or is invalid.
These situations are detected by the hardware of the computer and passed to the operating system as “interrupts”. This means that the operating system is to “interrupt” the thread that is currently executing a piece of code of the application, and cause the interrupt. Some of interrupts are expected by the computer, and are used to signal the operating system that something has happened in the hardware. Such expected interrupts are handled by the operating system. Other times, interrupts mean that the hardware is communicating to the operating system that an instruction of the application cannot be completed because of some “exceptional” conditions. These “exceptional” interrupts are known as “exceptions”.
Conventionally, applications do not have any mechanism that let themselves handle these exceptions programmatically. Thus, the operating system gets these exceptions first and, if the operating system is not able to handle the exception, it terminates the application as a default action of the operating system. Thus, the user does not have an opportunity to save its work prior to the termination of the application. Such premature termination of applications are caused by the life-cycle of these exceptions.
In the Microsoft Windows kernel (Win32), an exception handler is provided to handle exceptions occurred in Win32 applications. The exception handler has a process-wide top-level exception filter. The default action of the top-level exception filter is to terminate the application. When an exception occurs, the CPU of the computer suspends the current path of execution, and transfers control to the exception handler. Some exceptions are handled by the exception handler. Any exception that reaches the Win32 top-level exception filter will cause the application to close without saving any data.
Traditionally, this situation has been handled by having the application perform periodic saves while the application is running. Although this works well in any situation, including power failures, it still introduces a large “panic-factor” into any exceptional condition. Any changes made between a periodic save and the closing of the application will be lost. Basically, the application still fails even when something as catastrophic as a null pointer exception is encountered. Such a situation is unacceptable to the user.
Application recovery is the art of maintaining an application in an executable state regardless of internal conditions. There are some attempts to programmatically perform application recovery.
Microsoft File Recovery uses an on-demand repair which allows applications to repair themselves if they come across any problems during application execution. This program uses a management API of the Windows to programmatically determine the path to specific install package components that are installed on a computer. The primary use of their API is to enable the Windows Installer service to manage all file paths on behalf of the application. At run time, the application can ask the Windows Installer service for a path to a given component. If a file path problem occurs in an application at run time, the Windows Installer service can repair the problem by recopying the necessary files to the appropriate folder. However, this seems to deal with the file path problems only.
It is therefore desirable to provide a system and method which increases the chances of success of application recovery from runtime problems.